Hey! @thejonroberts

Trying to review this PR, mainly trying to get my head about the autosave json stuff. Could you explain this part a bit more (from the big PR):

Maintaining the autosave feature was complicated! Before, notes were the only thing that could change during an autosave, but now everything is in the form that gets sent during the autosave update. Therefore, nested_attributes_for contact_topic_answers and additional_expenses required a stimulus NestedForm controller that could create and destroy records -- otherwise, autosave would make new records for every save, or try to delete records that had already been removed in the prior update. This also required creating controllers & routes for those json requests.

If I understand you correctly you are saying on every form update(?) we create new contact topic answers and new additional expenses.

Doesn't the existing autosave just submit the form in the background with a debounce? It works with both notes and contact topic answers. What is breaking that behavior here?

Did you explore any other ways of retaining the autosave without the additional controllers? What were the issues?

@elasticspoon the relevant bits of the old flow were:

1. Select applicable ContactTopics during details step
2. Enter Answers for those 'selected' in 1 (& autosave on text value inputs)
3. Enter Expenses

Step 2 is the only step with autosave in effect. Since topics were already selected in step 1, you aren't adding new (non-persisted) ContactTopicAnswers, only changing the value of existing answers. (I don't think removing was an option, you could just sort of ignore the topics you didn't want to elaborate on). Therefore autosave can submit & re-submit the entire form, everything is already in the database, and it's update only.

Expenses/Step 3 doesn't autosave, so you can add/remove as much as you want without hitting the database until submission.

In the new, all-in-one form, you run into issues autosaving the form:

1. Adding an entry (topic answer or expense)
   • Add Note -> enter value -> autosave creates an Answer record...
   • Enter more info in same field -> autosave creates another record because form doesn't have an ID with the field, it was added after page load.
   • Submit or reload the page, you will have multiple records, one for each time autosave happened.
2. Deleting an entry
   • When editing an existing contact that has answers/expenses with IDs
   • Delete an item - form hides in display but marks hidden _destroy input true
   • Autosave should work fine once
   • Autosave again or submit will fail RecordNotFound because you've deleted the record already, but we tried to destroy it again.

Put simply, the form needs to be kept in sync with the database when associated records are created or destroyed. The form needs to know IDs of created records and when a record has been deleted, so that autosave can work.

The delete could probably be worked around / rescued somehow in the controller. But the Add problem requires the form to know IDs before it tries to autosave any database records.

The only other approach I thought of was something like:

# in update action method:
@case_contact.contact_topic_answers.destroy_all
@case_contact.additional_expenses.destroy_all
@case_contact.update(case_contact_params)

Deleting all the records just seems wrong... especially before an update... seemed too risky to me, if update fails, what then?

So I figured make the Add and Delete buttons a database-persisted action via these controllers, plus javascript (other PR) to update the form with the new IDs or removing deleted entries entirely (so they do not make a second destroy request).

@elasticspoon it seems like a good use of a turboframe - just replace the entire form on autosave.... but I worried about the response replacing an input as the user is interacting with it!
like user input, pauses -> (autosave request), user resumes typing -> that is replaced with autosave response (first input)

What you are saying makes sense. Thanks for the detailed explanation.

Deleting all the records just seems wrong... especially before an update... seemed too risky to me, if update fails, what then?

I guess you could wrap it in a transaction, but with it happening as often as it does, that might be an issue.

Closing as #6048 has gotten some feedback and is almost ready for review.